table.to_sql_filter Function
Syntax
Arguments
- expr
Character
- sep
Character
Description
If expression can be converted in whole OR partically to a SQL order, return the SQL portion, or both portions if a separator is provided.
Discussion
Takes an Xbasic syntax filter expression and converts it to a SQL syntax expression. If the entire filter cannot be converted to SQL, then converts part of the expression to SQL and shows the remainder that is still in Xbasic syntax. If the filter contains multiple clauses, joined with the .AND. operator, then it is possible that some of the clauses can be converted to SQL syntax, while other clauses cannot be converted (typically because they call a function that has no equivalent in the remote database). The separator defines the character string that will be used to separate the part of the filter that can be converted to SQL syntax, and the part that could not be converted. Assume that you have an active-link table on the sample 'customers' table from Northwind. Some of the active-link fieldnames are different than the corresponding fields in the remote table (assume that 'contactname' in the remote table is mapped to 'name' in the active-link table, and that 'region' in the remote table is mapped to 'state_region' in the active-link table).
Example
?t.to_sql_filter("name = \"john smith\" .and. state_region = \"ma\" .and. localUDF(companyname) = \"alpha\"","||")
= ContactName='john smith' and Region='ma'||localUDF(companyname)="alpha"In the above example, only part of the filter could be converted. The separator that was specified was '||', and so the portion that could not be converted is shown after the '||' string. The portion that could not be converted uses a function called 'localUDF()' which presumably does not exist on the remote database, and therefore this part of the filter clause cannot be converted. Note that in the part that is converted the '.and.' operator is changed to 'and' and the double quotes are converted to single quotes.